Florian Müllner [Tue, 16 Nov 2021 19:46:58 +0000 (20:46 +0100)]
shell/window-tracker: Track ::window-created
We currently track windows via MetaWorkspace's ::window-added and
::window-removed signals. Those aren't emitted for override-redirect
windows though, as those aren't actually located on any workspace
(see https://gitlab.gnome.org/GNOME/mutter/-/blob/gnome-41/src/core/window.c#L1322).
While that shouldn't be an issue as there's no good reason to look up
the ShellApp of an OR window, extensions can make modifications that
result in OR windows ending up in places that assume that every window
has an associated ShellApp.
We can either
- accept that extensions break stuff (including badly)
- carefully handle app-less windows everywhere
- extend tracking to OR windows
Opt for the last option, as that's the most user-friendly and least
disruptive one.
It's also simpler to track ::window-created and ::unmanaged, as we
don't have to track workspaces or windows moving between workspaces.
Florian Müllner [Tue, 16 Nov 2021 19:52:11 +0000 (20:52 +0100)]
shell/window-tracker: Track windows getting unmanaged
It makes sense to not rely on workspaces' ::window-removed
signal, and we already do that in ShellApp.
However it is odd to remove a tracked window from the app,
but still track it in the window tracker. Move the code
to remove unmanaged windows from both.
Florian Müllner [Thu, 11 Nov 2021 17:40:42 +0000 (18:40 +0100)]
shell/window-tracker: Do not filter tracked windows by type
The window-type property may change, and with it the skip-taskbar
property that decides whether we consider it "interesting".
As a result we can end up showing untracked window, i.e. one
which does not have an associated app.
Cover this case by simply tracking all windows regardless of
their type. This won't change the app's running state, as that
is solely based on the skip-taskbar property (which is enforced
for all previously excluded window types).
Sebastian Keller [Tue, 23 Nov 2021 01:48:04 +0000 (02:48 +0100)]
util: Wait for initial name owners in DBusSenderCheck before checking
Otherwise an allowed caller might get rejected if the call is right
after a gnome-shell restart and the watchers have not finished running
their callbacks yet.
Dylan McCall [Mon, 29 Nov 2021 00:19:35 +0000 (16:19 -0800)]
messageList: Give focus to next message on delete
When the user deletes a message using the keyboard, set the keyboard
focus to the next message, or to the list container itself, so it
remains possible to navigate using the keyboard.
calendar-server: Remove the all-day property of events
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Given the correct end date this code would be able to determine this
correctly itself and doesn't need to rely on that property. And events
without correct end dates are currently not shown anyway. This prepares
for removing the allDay property entirely.
This also fixes events going from 13:00 the current day to 01:00 not
showing "...". It also fixes multi-day events wrongly detected as
all-day events by the calendar-server showing up as "All day", despite
only covering 1 hour of the day.
Events with a date time (not just a date) where the end time is missing
or matching the start time were considered to not overlap the selected
interval if they were happening on the start time of the interval. This
was causing such zero-length events to be omitted from the calendar if
they were starting at 0:00.
calendar: Start ranges at 0:00 and iterate in whole days
Using a starting time other than 0:00 will prevent events before the
chosen starting time from showing up for that range. This was causing
events before 12:00 to be missing in the shell calendar on the first day
of a range.
Fix this by always starting at 0:00 and then incrementing by days rather
than a time value that depending on DST or leap seconds may or may not
correspond to a day.
dateMenu: Use intervals with non-inclusive ends for date ranges
The ical events, we are comparing these intervals to use the first point
in time after the end of the event as their end time, while the code in
gnome-shell was using the last point in time within the range. This was
causing multi-day events ranging from 0:00 to 0:00 to have a trailing
"..." shown on the last day.
Florian Müllner [Tue, 23 Nov 2021 19:19:14 +0000 (20:19 +0100)]
main: Warn when unsafe mode is toggled
MetaContext:unsafe-mode was added as a debugging tool to temporarily
remove restrictions on privileged APIs. But as it turns out, there
are now extensions that toggle the property permanently. Right now
none of them are malicious (as far as I can see), but it's still a
bad idea and should be discouraged.
Do this with a notification that warns the user when unsafe mode is
enabled non-interactively (i.e. via looking glass), and hopefully
also clarifies what the weird lock icon in the top bar is about.
magnifier: Remove call to dropped Clutter::get_default_frame_rate()
Clutter::get_default_frame_rate() has been removed in mutter!2002, but
it is still being used here. Given that this was basically hardcoded to
60 in mutter with the only way of changing this being an obscure
environment variable, just use that value here directly. This avoids a
crash when starting gnome-shell with the magnifier enabled.
libgnome-bluetooth will start to offer a 2.0 library version
depending on GTK4. Given that GNOME Shell already depends on
GTK3, it cannot use this next version of gnome-bluetooth. And
since GJS will automatically try and use the latest version
available of any library, Shell must specify it wants 1.0
explicitly.
Add a required GnomeBluetooth version number when importing it
for the status indicator.
magnifier: Disable desaturation effect when not in use
The desaturation effect was always enabled, regardless of the specified
factor. This was causing the magnifier to always hit offscreen
rendering, even when not necessary. Additionally offscreen rendering is
currently also causing glitches in MetaWindowGroup which this helps to
avoid in some cases.
Carlos Garnacho [Fri, 29 Oct 2021 14:46:18 +0000 (16:46 +0200)]
inputMethod: Do not reset invisible preedit on focus_out
If the preedit is in invisible state, the last preedit string that
was sent around is already null, so there is no need to clear the preedit
in that case.
Carlos Garnacho [Fri, 29 Oct 2021 14:43:15 +0000 (16:43 +0200)]
inputMethod: Do not communicate preedit text change on reset
This is now done in the ClutterInputFocus for us, since
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940. There
is no need to duplicate this call, and it happens to cause undesired
scrolling to content in some cases when this reset happens during
a change in the IM focused client state.
Florian Müllner [Tue, 26 Oct 2021 17:40:08 +0000 (19:40 +0200)]
dbusServices/extensions: Only allow one dialog at a time
Showing multiple preference dialogs at the same time (for instance
by repeated `gnome-extensions prefs` calls) may or may not work as
expected, depending on whether any of the dialogs is modal or not
(read: opened via the Extensions app).
The easiest way to address this is to disallow more than a single
dialog at the time. It's arguably also the more predictable behavior,
and means extensions don't have to deal with inconsistent state
caused by multiple dialogs.
Florian Müllner [Thu, 28 Oct 2021 17:27:57 +0000 (19:27 +0200)]
dbusServices/extensions: Fix shutdown after showing prefs
GTK4 relies entirely on refcounting for cleanup (that is,
there is no longer a destroy() method that forces a dispose
run regardless of the refcount).
Unfortunately that makes cleanup harder in (some) language
bindings, where an object may be kept alive implicitly by
closures etc.
Address this by releasing the hold count when the window
is closed rather than when it is destroyed.
This isn't the most elegant, but it ensure that the service
doesn't get stuck if an extension doesn't carefully clean
up everything in its prefs widget.
Florian Müllner [Thu, 28 Oct 2021 17:55:23 +0000 (19:55 +0200)]
extensions-tool/prefs: Log D-Bus errors
We currently ignore any error that may occur when calling the
OpenExtensionPrefs D-Bus method. Right now such an error is highly
unlikely, given that we already checked that we are running under
gnome-shell and the extension in question exists and has prefs.
We'll soon make sure that only one dialog is shown at any time,
which is an error that we can realistically expect, so handle that
properly.
Sebastian Keller [Sat, 30 Oct 2021 11:21:17 +0000 (13:21 +0200)]
shell/app: Don't move all workspace windows to their startup workspace
Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.
When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.
Florian Müllner [Thu, 21 Oct 2021 17:50:18 +0000 (19:50 +0200)]
environment: Apply autoReverse/repeatCount to all transitions
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.
Ray Strode [Tue, 10 Aug 2021 19:31:00 +0000 (15:31 -0400)]
sessionMode: Allow extensions at the login and unlock screens
Now extensions can specify which session modes they work in,
but specifying the login screen or unlock screen session modes in
an extensions metadata still won't work, because those session
modes disallow extensions.
Ray Strode [Sat, 28 Aug 2021 17:54:39 +0000 (13:54 -0400)]
extensionSystem: Allow extensions to run on the login screen
At the moment it's not realy possible to extend the login screen to do
things it doesn't have built-in support for. This means in order
to support niche use cases, those cases have to change the main
code base. For instance, oVirt and Vmware deployments want to be able
to automaticaly log in guest VMs when a user pre-authenticates through a
console on a management host. To support those use cases, we added
code to the login screen directly, even though most machines will never
be associated with oVirt or Vmware management hosts.
We also get requests from e.g. government users that need certain features
at the login screen that wouldn't get used much outside of government
deployments. For instance, we've gotten requests that a machine contains
prominently displays that it has "Top Secret" information.
All of these use cases seem like they would better handled via
extensions that could be installed in the specific deployments. The
problem is extensions only run in the user session, and get
disabled at the login screen automatically.
This commit changes that. Now extensions can specify in their metadata
via a new sessionModes property, which modes that want to run in. For
backward compatibility, if an extension doesn't specify which session
modes it works in, its assumed the extension only works in the user
session.
Ray Strode [Tue, 10 Aug 2021 17:25:57 +0000 (13:25 -0400)]
extensionSystem: Get rid of _enabled boolean optimization
At the moment a session mode either allows extensions or it doesn't.
If it allows extensions, then the entire available list of
configured extensions get enabled as soon as the session mode is
entered.
Since enabling or disabling extensions is an all or nothing situation,
the code tracks whether extensions are already enabled when entering
the session mode, and if so, avoids iterating through the extension list
needlessly. It does this using a boolean named _enabled.
In the future, the extensions themselves will be given some say on
whether or not they should be enabled in a given session mode. This
means, the configured extension list may contain extensions that
shouldn't be enabled for a given session mode, and the _enabled boolean
will no longer be appropriated.
This commit drops the _enabled boolean optimization.
Florian Müllner [Thu, 14 Oct 2021 16:53:17 +0000 (18:53 +0200)]
Post-branch mutter API bump
Since the CI pipeline now runs `meson dist` which includes a test
for an up-to-date NEWS entry, post-branch/release version bumps
have become unwieldy.
It's still useful to increase the API version right after branching
though, so return to bumping it manually and do so now.
Florian Müllner [Wed, 6 Oct 2021 16:51:03 +0000 (18:51 +0200)]
theme: Fix high-contrast switches
Commit 9d6fcfdc8506 dropped the different us/intl switches, but
the high-contrast theme was left out at the time (and therefore
ends up with the regular assets now).
Carlos Garnacho [Thu, 16 Sep 2021 08:03:38 +0000 (10:03 +0200)]
ci: Install mutter again on coverity job
This job "needs" the build job and thus gets its artifacts, but
it will not inherit the environment where we already installed
Mutter in /usr. This apparently broke once there was a more
recent mutter-clutter .pc file to look up.
Install Mutter in /usr again in this job, so the new build for
coverity finds all dependencies.
Ray Strode [Tue, 5 Oct 2021 15:01:19 +0000 (11:01 -0400)]
unlockDialog: Properly reset auth prompt when showing it
If a user hits escape twice really fast when coming back to
their machine to unlock it, they made end up getting presented
with a non-functional unlock screen that doesn't show their
user icon and doesn't ask for a password.
This is because showPrompt assumes that if an auth prompt already
exists, it's ready to go. That may not be true, if it's in the
process of getting torn down at the time because it's in the middle
of a cancel animation.
This commit solves the problem by ensuring the auth prompt is always
in a fresh reset state before showing it.
When commit 25bfe99ed53b5b7 replaced the thin libcanberra wrapper
with the (then) new MetaSoundPlayer API, it missed that the latter
expects files as GFile instead of a file path.
Commit dd2cd6286cd3 restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
st/icon: Ensure icons are updated if theme node is invalid
Icons that are changed while an actor is not mapped may not have a theme
node associated with, and thus we'd end up not updating them at all.
In fact we return early in st_update_icon(), and this was not an issue
until commit 0b1dfbf6f3f, because we'd end up to update the icon anyways
once the style was changed (and so with a valid theme node), but since
such change we might not updating the icon if no theme detail changed.
To prevent this, add a flag to require an icon update when the theme
changed, if no successfully update happened earlier.
Jonas Ådahl [Tue, 21 Sep 2021 14:35:32 +0000 (16:35 +0200)]
Always assume GLSL is supported
The support for GLSL has been advertised as unconditionally supported by
mutter for a while, and has now lost the 'GLSL' feature completely. Lets
remove the checks.
projects / gnome-shell.git / log